SuperHack/SuperHack CD.bin/CODING/GRAPHICS/VOXRAY.ZIP/RAYDEAL.TXT

Text File | 1996-03-21 | 16.8 KB | 428 lines

The Raydeal Game Faq v1.03
by Matt Howard, with irritating comments by Gene Buckle.

TOC

Section 1 The Game
 1.  What is the Raydeal game?
 2.  What still needs to be done to the game?
 3.  How will the game be marketed?
 4.  Who's involved in the project already?
 5.  How do I get involed? What's in it for me?
 6.  Misc.
 7.  The Future(!?)

Section 2 The Code
 1.  Programming Overview And Notes
 2.  File Structure
 3.  Known Bugs
 4.  Things to be fixed with the engine

Section 3 The History
 1. A brief history of raydeal
 2. A brief history of the FAQ

Section 1: The Game
---------------------------------

1.1  What is the Raydeal game?

The Raydeal game is a game based on the recently released Raydeal
game engine, also known as the Nottingham engine. The idea is to
create a much more stategic and expanded Deathmatch. In other
words, people will now not only be in charge of their own survival,
but will also control bases, defenses, etc. Teams of people will be
pitted against eachother, in charge of capturing their oppenents
base (or in a larger game, multiple bases). Hopefully, the end
result will be a ten on ten all out strategic war, all in real-time
3-d. It'll probably take a lot longer than a normal deathmatch.
Environments will be mostly outdoor forests and the like, while
base will be interior DOOM like buildings. Obviously levels will
all be a lot more complex in the real game.

The game will be developed to run across the internet. Various
computers will link into a server for a game.

It may be developed on Win95, but a DOS version will probably be
availible first.

-------------------------------------------------------------------

1.2 What still needs to be done to the game?

Debugging.  The engine needs to be completely debugged before we
get wildadding new features -TGOM[1]


Networking- I think this game should definitely be an
Internet game- it should also be playable over IPX networks.

Windows Port- This really ought to be finished. Coding networking
in Windows would be a lot easier, as it could just be a Winsock
app.

Level Editor plus Levels- A friend of mine wrote an editor a while
ago but it sucked (took me about three hours of hand editing to get
his level to work). A rewrite might be neccesary. We also thought
about random level generation, but that might be really impossible.
I think and editor is easier.

A lot of object coding- we need to setup how more defenses work, as
well as a system for placing them on the map.

Sound- just need to add support for other cards, plus some original
tunes written by other people

Graphics- we need better textures
-----------------------------------------------------------------
-----

1.3 How will the game be marketed?

We have no commercial publisher. We do not want one. The game will
be marketed freeware.

This last list sounds like a lot, but consider that if we're not up
to coding these, we can move on, since it doesn't have a commercial
publisher.

I think it'd be a good idea to get an early version availible as
soon as possible to build some hype.
-----------------------------------------------------------------
---------

1.4 Who is involved with the game already?

Currently, the de facto project leaders are myself (Matt Howard)
and Gene Buckle. This is only because, for the moment, we're the
ones doing the most work. Here is the complete list of people
involved:

Matt Howard ([e-mail])  Project creator & engine coder

Gene Buckle ([e-mail]) Head communications coder and the man
with the plan. (NOT! I'm the [1]Token Grouchy Old Man)(Sure Gene.
Oh, and the big vision at the bottom was written by, who?)

Brian Cowan ([e-mail]) Enthusiastic coder ready
to do anything

Dave Cornish ([e-mail]) The head artist so far

Andrew Warnick ([e-mail]) Willing to code net stuff and
also editor

Robert Parenton <[e-mail]> Artist/Coder

William Forsche <[e-mail]> Artist / Model maker

Matt Douglass ([e-mail]) Code Optimizer?

Josh Glazer ([e-mail]) ????
-----------------------------------------------------------------
-------------


1.5 How do I get involved? What's in it for me?

To become a coder, artist, musician, etc, all you have to do is
mail me. Tell me what parts of the game you would like to work on,
and I will get you in touch with the right people.

What do you get out of it? NOT MONEY. That's right. Since we're
making the game for free, no one's gonna get any cash. BUT, YOU GET
RECOGNITION. Game companies are constantly looking, almost above
all other factors, for people who've been involved on successful,
completed projects. This project can get you that. It also shows
you are a creative person will to take risks. In other words, be
involved on this project could be a great way to break into the
game industry.

Moreover, you get to be involved in a cutting edge production on
the sole condition that you're interested. Ya just can't find that
many other places.
-----------------------------------------------------------------
-------

1.6 Misc:

There is a discussion channel on us.undernet.org called #raydeal.
Either me (handle theweirdo) or Gene (tspectre) are almost always
there.

1.7 The Future:
---------------
Raydeal: The Vision. (or, "what other neat and impossible to code
things can I think of this afternoon?") by Gene Buckle

Imagine a game that had all the strategic elements of boardgames
like Risk or computer games like Empire, with all the in-your-face
death and destruction that Doom offers.  Sound good?  That's what
I'd like to see this game evolve into.

The game should not be constrained to only person to person ground
combat.  We can add vehichles!  Just think of the fun you could
have in a tank battle.  Tanks would be great, but why not add small
teams with mortars or howitzers?  From there, things like mine
fields could be added to add just the right amount of terror to the
ground pounders attacking your base!  The vehicle concept can be
taken another step further by adding small helicopters and
airplanes.  Now not only does Johnny Grunt have to worry about
tanks, trucks and minefields, but he as to look up as well to make
sure he doesn't get strafed by that crazy bastard flying the
airplane at 250 feet off the deck.  Helicopters could be used to
insert multi-player teams behind enemy lines for a little behind
the scenes special forces work.  From this, we can add all sorts of
nasty little goodies.  Things like LAAW and TOW missle launchers,
pillboxes with fixed guns (you can aim it, but you can't take it
with you), pit traps, etc.

Another expansion should be some kind of economic scale.  This
would entail team leaders having to buy (or steal!) equipment for
their team. Assets should not be inexhaustable either.  If a player
decides to waste a few dozen planes in suicide missions against
another players' fortress, those planes are *gone* until his
"factories" can build new planes, or he can buy or steal
replacements.  This would add a bit more "realism" to the game as
it's played out.  Players could respawn immediately if killed, but
if they were driving a tank at the time, they've got to either
obtain another one from the motor pool, or steal one from another
unsuspecting player.

Mercenary forces can also be used for those players that don't want
to align themselves with a particular team.  This opens up the
possibilty of groups of mercenary players attacking resupply
convoys and reselling the goods to the highest bidder.  A black
market of sorts.  This would also add a nice touch of realism to
the game.

There are limitless possibilities for the game as it stands, and if
we work together on this, a lot of it can become a reality!

As you can see, my particular vision for this great 3d game engine
that Matt has designed is quite vast.  Some of what I'd like to see
will never come to pass and some things that I've never thought of
before will be added.  The end result will be the same however.  A
game that can be played and enjoyed by *anyone* reguardless of how
quick their reflexes are or how smart they are.

By hosting the game on the internet, it will attract a lot of
players from many diverse backgrounds, which unto itself will add
to the entertainment of the whole.


----------------------------
And now, Matt will attempt to bring us all back to reality.
----------------------------

Section 2: The Code
----------------------------

2.1: Programming Overview And Notes

So far this is pretty brief. You'll have to make due till a more in
depth version comes out.

The following are notes to the reviewing programmer.
This program is spread out into several modules, many of which are
themselves several files large. In general, for source code names
which are not self-explanatory:
a file prefix means it has to do with world file i/o
a ray prefix either has to do with rendering or is from an
older time when all files were ray prefixed
a scr prefix means it has to do with screen management
an spr prefix means it has to do with sprites/objects
a vox prefix means it has to do with mountain rendering

Many of the sources are commented, but a few are not. In general,
its not at all cryptic code. I've tried to adhere to the general
philosophies of structured programming.

Important files:

gamerun.cpp - overall managing file. Runs almost everything
dosrun.cpp - actual location of main() in DOS version. Just turns
control over to gamerun.cpp
rayinit.cpp - starts up and shuts down most system independent
stuff
raycast.cpp + bsptree.cpp - make up the meat of the overall
renderer
sprrend.cpp - the sprite renderer
voxrend.cpp - c portion of mountain renderer
filemain.cpp - overall managing file for world file i/o
player.cpp - file that controls the player
ray.h - info given to almost all files
globals.h - global variables (I used to use globals, and now don't,
but I still have relics)
rayrend.h - h file for renderer
rayfile.h - h file for world file i/o
voxel.h - h file for mountain internal files
voxinter.h - h for for mountain external files that want to use
mountains
sprutils.h + rayspr.h + rayspr.h - h files for sprites

Command-line options:

-noshade turns off mountain shading
-fastvox makes mountains render faster but not as nicely
(does not effect shading)

I haven't tried these in a long time, so I don't know if they work:
-file uses alternate world file (will actually load DOOM wads too)
-ftex use alternate world for floor textures
-wtex same but for walls

A few idiosyncracies:

mix of the terms sprite and object- Technically, a sprite refers to
a specific type of object, on that rendered as a moving bitmap.
However, in the program the terms are interchanged without concern
for specific definition. When sprite is used, it sometimes refers
specifically to the rendering of an object

#ifdef OS_ lines
These refer to operating system dependent portions of the code.
A windows port was actually written for the project, but
unfortunately other aspects of the project to priority before I
could debug the WINDOWS version.

However, it actually compiled to windows at the time and ran,
albeit in a slightly screwed up fashion(sp?) (the color palette was
messed up). At this point, it probably will not compile cleanly to
Windows, though finishing the port would require only a day or two
for an experienced Windows programmer. (When I wrote the port, it
was the first Win program I'd ever written).

code for objects & function pointers associated with them- The
object model in the program is pretty neat. Rather than defining
the object types at compile time, object types are run-time defined
in the world file. Orchestrating this is not easy, and sometimes it
makes object code overly complex. However, it is interesting to
note that you could now, for example, put the camera in eye of an
enemy, or change one enemies pictures to change him form a human to
a monster. You should also note that some of the later object code
was written very close to the time a prototype was needed, and is
as a result somewhat cryptic and inflexible.

the asm files
sliver.asm- code for inner loop of rendering walls & floors
voxrow.asm- one set of code for inner loop of mountains (partially
shaded)
voxrowf.asm- secode set of mountain code (no shading)
vrsmooth.asm- final set of mountain code (full shading). This the
one that is almost universally used

-----------------------------------------------------------------
---------------------
2.2: Data file layouts

     A brief explanation of file structures-

     The only major native file structure to the engine is the .dat
file. It is very similar to a WAD file used in DOOM and its
succesors. The file begins with a header w/ stucture:

typedef struct WFHEADER {
   char header[8];
   long dir_entries;
   long dir_location;
   } WFHeader;

Header is a name, whose first letter signifies if this is a binary
('B') or text file ('T'). Currently, all created files have been
text.

dir_entries is the number of entrys in the directory, or list of
resources in the file. dir_location is the start of the directory.
It usually comes at the end of the file.

This list is made up of dir_entries number of info packets with
this structure:

typedef struct DIR_ENTRY {
   char name[8];
   long start;
   long length;
   } dir_entry;

name is the name of the resource,  start is location from the start
of the file of this resource, and length is the number of items of
this particular resource that this entry has.

For more information on individual resources, and the file
structure in general, read rayfile.h, and also the .cpp files w/
the file prefix.

-----------------------------------------------------------------
-----------------------
2.3: Current known bugs
    1. A mysterious bug plague's the sprite renderer. It is clear
that when trees, the most common sprite, is turned off, it rarely
crashes. This is a critical, program crashing bug
    2. Object and wall collision algorityms are sloppy.
Particularly wall collision. The cause objects to collide earlier
than they should, which in some cases causes objects to appear to
mysteriously dissapear. This should be rewritten or corrected as it
hampers playability.
   3. The is a bug in the BSP generator (Binary Space Tree),
although this has no obvious effects when running the program, it
causes the current Win version to crash on startup, and is known to
crash the program under a debugger.
   4. There may be more bugs in the renderer. These are most likely
non-fatal, but must be corrected nonetheless
   5. This is not an adequate list. I'll be the first to admit the
program is way too buggy.

-----------------------------------------------------------------
----------------------
2.4: Things needed to finalize game engine.

     The game engine itself is fairly complete. Various player
movements need to be worked out, such as stafing, and control in
general is not that well worked out.

Section 3: The History
-----------------------------

3.1: A brief history of raydeal

Raydeal begins in when I'm in 11th grade. I code a DOOM engine and
a voxel engine concurrently. I have the initial game idea of BOLO
with a DOOM interface. Josh Glazer is initially involved, and codes
a MAC port, and an editor, which never works. He eventually loses
interest, sorta.

At the end of 11th grade, I get hired by Cortina Entertainment, who
wants to make a game out of my work. I take the program all the way
to a prototype stage, almost finishing by the end of summer (w/
actual completion by Sept/Oct.).

It then sits on the HD gathering dust for about 6 months, while
Cortina "evaluates" it. I've never heard from them, though they
claim to still be doing the project.

Say what???? You mean this is 6 month old technology???? Yes, a
fairly unintelligent Hollywood game company didn't realize the
potential of the technology someone was offering them, and the game
sat there for six months.

I eventually post a homepage, in which I decide to publish the
entire source code. Why? Primarily because I 've learned that in an
insatiable quest to make money, I let the technology get slightly
old. I could have given a head start to amateur coders around the
world.

Various people, particularly Gene, express interest in continuing
the project. With no corporate beuracracy, no funding, no money to
make, and just vision and a desire to make a damn cool game, we get
going again.


-----------------------------------------------------------------
---------------------
3.2: A brief history of the FAQ

1.0 Matt scribles something down in WordPad
1.01 Gene structures the FAQ, and adds his vision
1.02 Matt fills in some sections for gene, and adds history.
1.03 Matt makes corrections, and the FAQ is ready for posting